IP Multimedia (IPMM) is an example of a service that provides a dynamic combination of voice, video, messaging, data, etc, within the same session. By growing the numbers of basic applications and the media that it is possible to combine, the number of services offered to the end users will grow, and the inter-personal communication experience will be enriched. This will lead to a new generation of personalised, rich multimedia communication services, e.g. peer-to-peer multimedia communication, IPTV etc.
These services can be based on the IP Multimedia Subsystem (IMS) architecture, which is the technology defined by the Third Generation Partnership Project (3GPP) to provide IP Multimedia services over mobile communication networks (3GPP TS 22.228, TS 23.228, TS 24.229, TS 29.228, TS 29.229, TS 29.328 and TS 29.329 Releases 5 to 7).
The IMS makes use of the Session Initiation Protocol (SIP) to set up and control calls or sessions between user terminals (or user terminals and application servers). The Session Description Protocol (SDP), carried by SIP signalling, is used to describe and negotiate the media components of the session. FIG. 1 illustrates schematically how the IMS fits into the mobile network architecture in the case of a 3GPP PS access domain.
Services can be provided to a user via an IMS network using an Application Server (AS). Service provision is triggered using one or more Initial Filter Criteria (IFC), stored in a user's profile and downloaded to the user's Serving-Call Session Control Function (S-SCSF) when the user registers with the IMS network. An IFC is composed of trigger points and the address of one or more AS. The trigger point describes conditions that must be checked to discover whether or not the indicated AS should be contacted.
As illustrated in FIG. 2, when the S-CSCF receives a message, it checks the stored IFCs. If the incoming message meets the conditions of the trigger point in an IFC, then the S-CSCF passes the message to the AS indicated by the IFC. Once the AS has dealt with the message, the message is returned to the S-CSCF and the next IFC is checked. An IFC can be accorded a priority number, so if more than one IFC relating to a user is stored at the S-CSCF, the IFCs are checked in the order of priority.
The interface between the S-CSCF and the AS is the IMS Service Control (ISC) interface, which uses SIP signalling to communicate between the AS and the S-CSCF.
3GPP IMS specification TS 24.229 v7.5.1 provides a mechanism that allows an AS to perform a change of target of the SIP request, by modifying the Request-URI (Uniform Resource Indicator) contained in the message. When the message is returned from the AS to the S-CSCF, the S-CSCF detects the change of request-URI and interrupts checking of the Initial Filter Criteria (IFC) evaluation, as shown in FIG. 3. The message is passed directly to outgoing request handling, and any lower priority IFCs are not checked, which prevents invocation of other ASs.
The original motivation for the mechanism arose from the requirement of a call forwarding service, which allows an AS to alter the destination address of the SIP request. At the time, it was not envisaged that any other service would require that the AS should change the Request-URI of the SIP request. However, there are now cases being considered that may require the AS to change the Request-URI of the SIP request, but which should not interrupt the IFC evaluation procedure at the S-CSCF. Examples of such cases include the following:                1. A user having an IMS Public User Identity (IMPU) may be using more than one UE. The AS receives a request that is addressed to the IMPU of a user, and selects a SIP User Agent (UA), typically a terminal of the user addressed with a Globally Routable UA URI (GRUU) or a Contact, as an endpoint. When the AS wants to initiate a terminating session with the User Equipment (UE) a problem arises if the IMPU assigned to the UE is shared by other UEs. To fully control which UE the terminating session request is sent to, the AS must change the target of the request from the IMPU to the address of the selected endpoint.        2. A similar issue arises when the AS changes the user's IMPU. This may be required, for example, when the AS receives an IMPU with TEL URI and sends another one with a SIP URI or vice versa.        3. The AS may be required to change the Request-URI of the incoming request from a SIP URI to a Tel URI. This change is needed as devices connected to the network using the Public Switched Telephone Network (PSTN) can only be contacted using telephone numbers.        
In the above two cases, it may be desirable for the S-CSCF to continue IFC evaluation after the Request-URI in the message has been changed by an AS. This does not change the targeted user, but merely addresses the same user or a subset of the user's endpoints using an alternative address. This is different from the “call forwarding” scenario where the actual target user is changed, and is the primary reason why the existing mechanism of interrupting IFC evaluation in the event of a change of address is not suitable for these cases.